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Abstract 


The 6bone was established in 1996 by the IETF as an IPv6 Testbed 
network to enable various IPv6 testing as well as to assist in the 
transitioning of IPv6 into the Internet. It operates under the IPv6 
address allocation 3FFE::/16 from RFC 2471. As IPv6 is beginning its 
production deployment it is appropriate to plan for the phaseout of 
the 6bone. This document establishes a plan for a multi-year 
phaseout of the 6bone and its address allocation on the assumption 
that the IETF is the appropriate place to determine this. 


This document obsoletes RFC 2471, "IPv6é Testing Address Allocation", 
December, 1998. RFC 2471 will become historic. 


1. Introduction 


The 6bone IPv6 Testbed network was established in March 1996, 
becoming operational during the summer of 1996 using an IPv6 testing 
address allocation of 5F00::/8 [TEST-OLD] that used the original (and 
now obsolete) provider based unicast address format. In July 1998, a 
new IPv6é Addressing Architecture [ARCH] replaced the original 
provider based unicast address format with the now standardized 
Aggregatable Global Unicast Address Format [AGGR]. 


To allow the 6bone to operate under the revised IPv6 address 
architecture with the new Aggregatable Global Unicast addressing 
format, [TEST-OLD] was replaced with a new IPv6 testing address 
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allocation" of 3FFE::/16 in [TEST-NEW]. During the fall of 1998, in 
anticipation of [AGGR], the 6bone was re-addressed under the 
3FFE::/16 prefix with little problems. 


From the fall of 1998, until the issuance of this note, the 6bone has 
continued to successfully operate with Aggregatable Global Unicast 
Address prefixes from the 3FFE::/16 allocation, using a set of 6bone 
routing practice rules specified in [GUIDE], and later refined to 
6Bone backbone routing guidelines in [PRACTICE]. 


During its lifetime the 6bone has provided: 


- a place for early standard developers and implementers to test 
out the IPv6 protocols and their implementations; 


- a place for early experimentation with routing and operational 
procedures; 


- a place to evolve practices useful for production IPv6é prefix 
allocation; 


- a place to provide bootstrap qualification for production IPv6 
address prefix allocation; 


— a place to develop IPv6 applications; 


- a place for early users to try using IPv6 in their hosts and 
networks. 


As clearly stated in [TEST-NEW], the addresses for the 6bone are 
temporary and will be reclaimed in the future. It further states 
that all users of these addresses (within the 3FFE::/16 prefix) will 
be required to renumber at some time in the future. 


Since 1999 planning for, and allocation of, IPv6 production address 
prefixes by the Regional Internet Registry (RIR) community has been 
underway. During 2002 more production IPv6 address prefixes had been 
allocated than are allocated by the 6bone at the top level. It is 
generally assumed that this is one reasonable indicator that planning 
for a 6bone phaseout should begin. 


It is generally assumed that there is still some remaining need for 
the 6bone, at least for current usage that will take time to evaluate 
and possibly move to production IPv6 networks when possible. 


It is generally viewed that the 6bone is an IETF activity as it was 


established by IETF participants to assist the IETF in developing 
IPv6 protocols, and also to assist in the IPv6 transition. To this 
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end, the [TEST-NEW] RFC specified that the 6bone testing was to be 
under the auspices of the IETF IPng Transition (ngtrans) Working 
Group 6bone testbed activity. However, during 2002 the ngtrans 
working group was terminated and replaced to a certain degree by the 
v6ops working group, which did not include oversight of the 6bone in 
its charter. Therefore it is assumed that it is appropriate to use 
the IETF Informational RFC process to determine a 6bone phaseout 
plan, as well as an appropriate way to get community feedback on the 
specifics of the 6bone phaseout. 


This plan for a 6bone phaseout specifies a multi-year phaseout 
timeline to allow sufficient time for continuing operation of the 
6bone, followed by a sufficient time for 6bone participants to 
convert to production IPv6 address prefixes allocated by the relevant 
Regional Internet Registry (RIR), National Internet Registry, or 
Local Internet Registries (ISPs). 


It is anticipated that under this phaseout plan the 6bone will cease 
to operate by June 6, 2006, with all 6bone prefixes fully reclaimed 
by the IANA. 


This document obsoletes RFC 2471, "IPv6é Testing Address Allocation", 
December, 1998. RFC 2471 will become historic. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


2. 6bone Phaseout Plan 


To provide for the continuing useful operation of the 6bone, to the 
extent that IETF consensus judges it to be useful, 6bone top level 
address prefixes known as pseudo TLA’s (pTLAs) MAY continue to be 
allocated until January 1, 2004. 


Thus after the pTLA allocation cutoff date January 1, 2004, it is 
REQUIRED that no new 6bone 3FFE pTLAs be allocated. 


To provide for sufficient planning time for 6bone participants to 
convert to production IPv6 address prefixes, all 6bone prefixes 
allocated by the cutoff time specified above, except for allocations 
withdrawn as a matter of 6bone operating procedures, SHALL remain 
valid until June 6, 2006. 


Thus after the 6bone phaseout date June 6, 2006, it is the intent 
that no 6bone 3FFE prefixes, of any size/length, be used on the 


Internet in any form. Network operators may filter 3FFE prefixes on 
their borders to ensure these prefixes are not misused. 
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It should be noted that this RFC does not intend to imply that a 
6bone prefix holder, whether at the pTLA top level or lower, should 
seek a production IPv6 address prefix at any specific level. It may 
be entirely reasonable for a 6bone prefix holder to seek a higher 
level, or a lower level, IPv6 prefix as their specific needs dictate. 
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5. Security Considerations 
This document defines a phaseout plan for the usage of the IPv6 
Testing Address Allocation [TEST-NEW], which uses addresses 
consistent with [AGGR]. It does not have any direct impact on 
Internet infrastructure security. 

6. IANA Considerations 
This document defines a phaseout plan for the usage of the IPv6 


Testing Address Allocation [TEST-NEW]. The IANA MUST reclaim the 
3FFE::/16 prefix upon the date specified in section 2.0. 
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When the 6bone Testing Address Allocation is reclaimed by the IANA, 
it is expected that many network operators will filter it on their 
borders to ensure these prefixes are not misused. 


There is experience from the IPv4 world that such filters may not be 
removed promptly should this address space be reallocated, and it is 
recommended that the IANA bears this in mind before reallocating it 
in a manner that would require it to be routed globally within the 
current Internet. 
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Copyright (C) The Internet Society (2004). This document is subject 
to the rights, licenses and restrictions contained in BCP 78 and 
except as set forth therein, the authors retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 

REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed 
to pertain to the implementation or use of the technology 
described in this document or the extent to which any license 
under such rights might or might not be available; nor does it 
represent that it has made any independent effort to identify any 
such rights. Information on the procedures with respect to 

rights in RFC documents can be found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use 
of such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository 
at http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention 
any copyrights, patents or patent applications, or other 
proprietary rights that may cover technology that may be required 
to implement this standard. Please address the information to the 
IETF at ietf-ipr@ietf.org. 
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